<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

  <head>
    <meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
    <title>Generic Reference Driver</title>
    <link href="scripts/style.css" type="text/css" rel="stylesheet">
  </head>

  <body>
    <h3>Generic Reference Driver</h3>
<p>Last update:
  <!-- #BeginDate format:En2m -->27-Jan-2014  05:31<!-- #EndDate -->
  UTC</p>
    <hr>
    <h4>Synopsis</h4>
    Address: 127.127.8.<em>u</em><br>
    Reference ID: PARSE<br>
    Driver ID: GENERIC<br>
    Serial Port: /dev/refclock-<em>u</em>; TTY mode according to clock type<br>
    PPS device: /dev/refclockpps-<em>u</em>; alternate PPS device (if not available via the serial port)
    <h4>Description</h4>
    The PARSE driver supports 20 different clock types/configurations. PARSE is actually a multi-clock driver.<br>
    <br>
    <p>The  actual receiver status is mapped into various synchronization states  generally used by receivers. The driver is configured to interpret the  time codes of Meinberg DCF77 AM receivers, DCF77 FM receivers, Meinberg  GPS16x/17x receivers, Trimble SV6 GPS, ELV DCF7000, Schmid, Wharton  400A and low cost receivers (see <a href="imap://mills@mail.eecis.udel.edu:993/fetch%3EUID%3E.INBOX%3E67132?part=1.3&type=text/html&filename=driver8.html#clocklist">list below</a>).</p>
    <p>The  reference clock support in NTP contains the necessary configuration  tables for those receivers. In addition to supporting several different  clock types and up to 4 devices, the processing of a PPS signal is also  provided as a configuration option. The PPS configuration option uses  the receiver-generated time stamps for feeding the PPS loopfilter  control for much finer clock synchronization.</p>
    <p>CAUTION: The  PPS configuration option is different from the hardware PPS signal,  which is also supported (see below), as it controls the way ntpd is  synchronized to the reference clock, while the hardware PPS signal  controls the way time offsets are determined.</p>
    <p>The use of the PPS option requires receivers with an accuracy of better than 1ms.</p>
    <h4>Timecode variables listed by ntpq (8)</h4>
    <p>The ntpq program can read and display several clock variables. These hold the following information:</p>
    <dl>
      <dt>refclock_format</dt>
      <dd>A qualification of the decoded time code format.</dd>
      <dt>refclock_states</dt>
      <dd>The overall running time and the accumulated times for the clock event states.</dd>
      <dt>refclock_status</dt>
      <dd>Lists the currently active receiver flags. Additional feature flags for the receiver are optionally listed in parentheses.</dd>
      <dt>refclock_time</dt>
      <dd>The local time with the offset to UTC (format HHMM).</dd>
      <dt>timecode</dt>
      <dd>The actual time code.</dd>
    </dl>
    <p>If PPS information is present, additional variables are available:</p>
    <dl>
      <dt>refclock_ppsskew</dt>
      <dd>The difference between the RS-232-derived timestamp and the PPS timestamp.</dd>
      <dt>refclock_ppstime</dt>
      <dd>The PPS timestamp.</dd>
    </dl>
    <h4>Supported Devices</h4>
    <p>Currently, twenty-four clock types are supported by the PARSE driver and up to four (devices /dev/refclock-0 - /dev/refclock-3) of these clocks may be operational at any one time.<br>
      A note on the implementations:</p>
    <ul>
      <li>These  implementations were mainly done without actual access to the hardware,  thus not all implementations provide full support. The development was  done with the help of many kind souls who had the hardware and kindly  lent me their time and patience during the development and debugging  cycle. Thus for continued support and quality, direct access to the  receivers is a big help. Nevertheless I am not prepared to buy these  reference clocks - donations to (<a href="mailto:kardel%20%3CAT%3E%20ntp.org">kardel &lt;AT&gt; ntp.org</a>) are welcome as long as they work within Europe 8-).
	<p>Verified implementations are:</p>
	<ul>
	  <li>RAWDCF variants
	    <p>These variants have been tested for correct decoding with my own homegrown  receivers. Interfacing with specific commercial products may involve  some fiddling with cables. In particular, commercial RAWDCF receivers  have a seemingly unlimited number of ways to draw power from the RS-232  port and to encode the DCF77 datastream. You are mainly on your own  here unless I have a sample of the receiver.</p>
	  </li>
	  <li><a href="http://www.meinberg.de">Meinberg clocks</a>
            <p>These implementations have been verified by the Meinberg people themselves and I have access to one of these clocks.</p>
	  </li>
	  <li><a href="http://www.selinc.com">Schweitzer Engineering
	      Laboratories SEL-240x clocks</a>
            <p>This implementation was provided and verified by SEL and <a
		href="http://networktimefoundation.org">Network Time Foundation</a>
	      has an SEL-2407 in one of its development labs.</p>
	  </li>
	</ul>
      </li>
    </ul>
    <p>The pictures below have been taken from and are linked to the vendors' web pages.</p>
    <a name="clocklist"></a>
    <ul>
      <li><strong>server 127.127.8.0-3 mode 0</strong>
	<p><strong><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/timesource.htm#dcf---freq_sync">PZF5xx receiver family</a> (FM demodulation/TCXO / 50&mu;s)</strong><br>
          <br>
	</p>
      </li>
      <li><strong>server 127.127.8.0-3 mode 1</strong>
	<p><strong><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/timesource.htm#dcf---freq_sync">PZF5xx receiver family</a> (FM demodulation/OCXO / 50&mu;s)</strong><br>
          <a href="http://www.meinberg.de/english/products/pzf-eurocard.htm"><img src="../pic/pzf511.jpg" alt="Image PZF511" align="top" border="0" height="300" width="260"></a><br>
          <br>
	</p>
      </li>
      <li><a name="mode2"></a><strong>server 127.127.8.0-3 mode 2</strong>
	<p><strong><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/c51.htm">DCF C51 receiver and similar</a> (AM demodulation / 4ms)</strong><br>
          <a href="http://www.meinberg.de/english/products/c51.htm"><img src="../pic/c51.jpg" alt="Image C51" align="top" border="0" height="239" width="330"></a><br>
	</p>
	<p>This mode expects the Meinberg standard time string format with 9600/7E2.</p>
	<p><strong>Note:</strong> mode 2 must also be used for <a href="http://www.meinberg.de/english/products/formfactor.htm#slot_card">Meinberg PCI cards</a> under Linux, e.g. <a href="http://www.meinberg.de/english/products/gps-pcicard.htm">the GPS PCI card</a> or <a href="http://www.meinberg.de/english/products/dcf-pcicard.htm">the DCF77 PCI card</a>. Please note the <a href="http://www.meinberg.de/english/sw/#linux">Meinberg Linux driver</a> must be installed. That driver emulates a refclock device in order to  allow ntpd to access those cards. For details, please refer to the  README file that comes with the Meinberg driver package.<br>
          <br>
	</p>
      </li>
      <li><strong>server 127.127.8.0-3 mode 3</strong>
	<p><strong><a href="http://www.elv.de">ELV</a> DCF7000 (sloppy AM demodulation / 50ms)</strong><br>
          <br>
	</p>
      </li>
      <li><strong>server 127.127.8.0-3 mode 4</strong>
	<p><strong>Walter Schmid DCF receiver Kit (AM demodulation / 1ms)</strong><br>
          <br>
	</p>
      </li>
      <li><strong>server 127.127.8.0-3 mode 5</strong>
	<p><strong>RAW DCF77 100/200ms pulses (Conrad DCF77 receiver module / 5ms)</strong><br>
          <br>
	</p>
      </li>
      <li><strong>server 127.127.8.0-3 mode 6</strong>
	<p><strong>RAW DCF77 100/200ms pulses (TimeBrick DCF77 receiver module / 5ms)</strong><br>
          <br>
	</p>
      </li>
      <li><strong>server 127.127.8.0-3 mode 7</strong>
	<p><strong><a href="http://www.meinberg.de">Meinberg</a> <a href="http://www.meinberg.de/english/products/timesource.htm#gps---freq_sync">GPS16x/GPS17x receivers</a> (GPS / &lt;&lt;1&mu;s)</strong><br>
          <a href="http://www.meinberg.de/english/products/gps-eurocard.htm"><img src="../pic/gps167.jpg" alt="Image GPS167" align="top" border="0" height="300" width="280"></a><br>
	</p>
	<p>This mode expects either the University of Erlangen time string format or the Meinberg standard time string format at 19200/8N1.</p>
	<p>The  University of Erlangen format is preferred. Newer Meinberg GPS  receivers can be configured to transmit that format; for older devices,  a special firmware version may be available.</p>
	<p>In this mode some additional GPS receiver status information is also read. However, this requires a point-to-point connection. <a href="imap://mills@mail.eecis.udel.edu:993/fetch%3EUID%3E.INBOX%3E67132?part=1.3&type=text/html&filename=driver8.html#mode18">Mode 18</a> should be used if the device is accessed by a multidrop connection.</p>
	<p><strong>Note:</strong> mode 7 must not be used with Meinberg PCI cards; use <a href="imap://mills@mail.eecis.udel.edu:993/fetch%3EUID%3E.INBOX%3E67132?part=1.3&type=text/html&filename=driver8.html#mode2">mode 2</a> instead.<br>
          <br>
	</p>
      </li>
      <li><strong>server 127.127.8.0-3 mode 8</strong>
	<p><strong><a href="http://www.igel.de">IGEL</a> <a href="http://www.igel.de/eigelmn.html">clock</a></strong><br>
          <a href="http://www.igel.de/eigelmn.html"><img src="../pic/igclock.gif" alt="Image IGEL clock" border="0" height="174" width="200"></a><br>
          <br>
	</p>
      </li>
      <li><strong>server 127.127.8.0-3 mode 9</strong>
	<p><strong><a href="http://www.trimble.com">Trimble</a> <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.html">SVeeSix GPS receiver</a> TAIP protocol (GPS / &lt;&lt;1&mu;s)</strong><br>
          <br>
	</p>
      </li>
      <li><strong>server 127.127.8.0-3 mode 10</strong>
	<p><strong><a href="http://www.trimble.com">Trimble</a> <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.html">SVeeSix GPS receiver</a> TSIP protocol (GPS / &lt;&lt;1&mu;s) (no kernel support yet)</strong><br>
          <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om011.html"><img src="../pic/pd_om011.gif" alt="Image SVeeSix-CM3" align="top" border="0" height="100" width="420"></a><br>
          <a href="http://www.trimble.com/cgi/omprod.cgi/pd_om006.html"><img src="../pic/pd_om006.gif" alt="Image Lassen-SK8" border="0" height="100" width="420"></a><br>
          <br>
	</p>
      </li>
      <li><strong>server 127.127.8.0-3 mode 11</strong>
	<p><strong>Radiocode Clocks Ltd RCC 8000 Intelligent Off-Air Master Clock support </strong><br>
          <br>
	</p>
      </li>
      <li><strong>server 127.127.8.0-3 mode 12</strong>
	<p><strong><a href="http://www.hopf-time.com">HOPF</a> <a href="http://www.hopf-time.com/kart6021.html">Funkuhr 6021</a></strong><br>
          <a href="http://www.hopf-time.com/engl/kart6021.html"><img src="../pic/fg6021.gif" alt="Image DCF77 Interface Board" align="top" border="0" height="207" width="238"></a><br>
          <br>
	</p>
      </li>
      <li><strong>server 127.127.8.0-3 mode 13</strong>
	<p><strong>Diem's Computime Radio Clock</strong><br>
          <br>
	</p>
      </li>
      <li><strong>server 127.127.8.0-3 mode 14</strong>
	<p><strong>RAWDCF receiver (DTR=high/RTS=low)</strong><br>
          <br>
	</p>
      </li>
      <li><strong>server 127.127.8.0-3 mode 15</strong>
	<p><strong>WHARTON 400A Series Clocks with a 404.2 Serial Interface</strong><br>
          <br>
	</p>
      </li>
      <li><strong>server 127.127.8.0-3 mode 16</strong>
	<p><strong>RAWDCF receiver (DTR=low/RTS=high) </strong><br>
          <br>
	</p>
      </li>
      <li><strong>server 127.127.8.0-3 mode 17</strong>
	<p><strong>VARITEXT Receiver (MSF) </strong><br>
          <br>
	</p>
      </li>
      <li><a name="mode18"></a><strong>server 127.127.8.0-3 mode 18</strong>
	<p><strong><a href="http://www.meinberg.de">Meinberg </a><a href="http://www.meinberg.de/english/products/timesource.htm#gps---freq_sync">GPS16x/GPS17x receivers</a> (GPS / &lt;&lt;1&mu;s)</strong><br>
	</p>
	<p>This  mode works without additional data communication (version, GPS status  etc.) and thus should be used with multidrop, heterogeneous multiclient  operation.</p>
	<p><strong>Note:</strong> mode 18 must not be used with Meinberg PCI cards, use mode 2 instead.<br>
          <br>
	</p>
      </li>
      <li><strong>server 127.127.8.0-3 mode 19</strong>
	<p><strong>Gude Analog- und Digitalsystem GmbH 'Expert mouseCLOCK USB v2.0'</strong><br>
          <br>
	</p>
      </li>
      <li><strong>server 127.127.8.0-3 mode 20</strong>
	<p><strong>RAWDCF receiver similar to mode 14, but operating @ 75 baud (DTR=high/RTS=low)</strong><br>
	</p>
	<p>Driving  the DCF clocks at 75 baud may help to get them to work with a bunch of  common USB serial converters, that do 75 but cannot do 50 baud at all,  e.g. those based on Prolific PL2303. <br>
	</p>
      </li>
      <li><strong>server 127.127.8.0-3 mode 21</strong>
	<p><strong>RAWDCF receiver similar to mode 16, but operating @ 75 baud (DTR=low/RTS=high) </strong><br>
	</p>
	<p>See comment from mode 20 clock. <br>
	</p>
      </li>
      <li><strong>server 127.127.8.0-3 mode 22</strong>
	<p><strong>MEINBERG, mode 2 but with POWERUP trust </strong><br>
	</p>
      </li>
      <li><strong>server 127.127.8.0-3 mode 23</strong>
	<p><strong>MEINBERG, mode 7 but with POWERUP trust </strong><br>
	</p>
      </li>
      <li><strong>server 127.127.8.0-3 mode 24</strong>
	<p><strong><a href="http://www.selinc.com/">Schweitzer Engineering Laboratories</a></strong><br>
	</p>
      </li>
    </ul>
    <p>Actual data formats and setup requirements of the various clocks can be found in <a href="../parsedata.html">NTP PARSE clock data formats</a>.</p>
    <h4>Operation</h4>
    <p>The  reference clock support software carefully monitors the state  transitions of the receiver. All state changes and exceptional events  (such as loss of time code transmission) are logged via the syslog  facility. Every hour a summary of the accumulated times for the clock  states is listed via syslog.</p>
    <p>PPS support is only available  when the receiver is completely synchronized. The receiver is believed  to deliver correct time for an additional period of time after losing  synchronization, unless a disruption in time code transmission is  detected (possible power loss). The trust period is dependent on the  receiver oscillator and thus is a function of clock type.</p>
    <p>Raw  DCF77 pulses can be fed via a level converter to the RXD pin of an  RS-232 serial port (pin 3 of a 25-pin connector or pin 2 of a 9-pin  connector). The telegrams are decoded and used for synchronization.  DCF77 AM receivers can be bought for as little as $25. The accuracy is  dependent on the receiver and is somewhere between 2ms (expensive) and  10ms (cheap). Synchronization ceases when reception of the DCF77 signal  deteriorates, since no backup oscillator is available as usually found  in other reference clock receivers. So it is important to have a good  place for the DCF77 antenna. During transmitter shutdowns you are out  of luck unless you have other NTP servers with alternate time sources  available.</p>
    <p>In addition to the PPS loopfilter control, a true  PPS hardware signal can be utilized via the PPSAPI interface. PPS  pulses are usually fed via a level converter to the DCD pin of an  RS-232 serial port (pin 8 of a 25-pin connector or pin 1 of a 9-pin  connector). To select PPS support, the mode parameter is the mode value  as above plus 128. If 128 is not added to the mode value, PPS will be  detected to be available but will not be used. </p>
    <h4>Hardware PPS support<br>
    </h4>
    <p>For PPS to be used, add 128 to the mode parameter.</p>
    <p>If  the PPS signal is fed in from a device different from the device  providing the serial communication (/dev/refclock-{0..3}), this device  is configured as /dev/refclockpps-{0..3}. This allows the PPS  information to be fed in e.g. via the parallel port (if supported by  the underlying operation system) and the date/time telegrams to be  handled via the serial port.</p>
    <h4>Monitor Data</h4>
    <p>Clock  state statistics are written hourly to the syslog service. Online  information can be found by examining the clock variables via the ntpq cv command.<br>
      Some devices have quite extensive additional information  (GPS16x/GPS17x, Trimble). The driver reads out much of the internal GPS  data and makes it accessible via clock variables. To find out about  additional variable names, query for the clock_var_list variable on a  specific clock association as shown below. </p>
    <p>First let ntpq display the table of associations:</p>
    <pre>  ntpq&gt; as    ind assID status  conf reach auth condition  last_event cnt    ===========================================================      1 19556  9154   yes   yes  none falsetick   reachable  5      2 19557  9435   yes   yes  none  candidat  clock expt  3      3 19558  9714   yes   yes  none  pps.peer   reachable  1  		</pre>
    <p>Then  switch to raw output. This may be required because of display  limitations in ntpq/ntpd - so large lists need to be retrieved in  several queries.</p>
    <pre>  ntpq&gt; raw    Output set to raw  		</pre>
    <p>Use the cv command to read the list of clock variables of a selected association:</p>
    <pre>  ntpq&gt; cv 19557 clock_var_list  		</pre>
    <p>The long output of the command above looks similar to:</p>
    <pre>  assID=19557 status=0x0000,    clock_var_list="type,timecode,poll,noreply,badformat,baddata,fudgetime1,    fudgetime2,stratum,refid,flags,device,clock_var_list,refclock_time,refclock_status,    refclock_format,refclock_states,refclock_id,refclock_iomode,refclock_driver_version,    meinberg_gps_status,gps_utc_correction,gps_message,meinberg_antenna_status,gps_tot_51,    gps_tot_63,gps_t0a,gps_cfg[1],gps_health[1],gps_cfg[2],gps_health[2],gps_cfg[3],    gps_health[3],gps_cfg[4],gps_health[4],gps_cfg[5]"  		</pre>
    <p>Then use the cv command again to list selected clock variables. The following command must be entered as a single line:</p>
    <pre>  ntpq&gt; cv 19557 refclock_status,refclock_format,refclock_states,refclock_id,    refclock_iomode,refclock_driver_version,meinberg_gps_status,gps_utc_correction,    gps_message,meinberg_antenna_status,gps_tot_51,gps_tot_63,gps_t0a,gps_cfg[1],    gps_health[1],gps_cfg[2],gps_health[2],gps_cfg[3],gps_health[3],gps_cfg[4],    gps_health[4],gps_cfg[5]  		</pre>
    <p>The output of the command above is wrapped around depending on the screen width and looks similar to:</p>
    <pre>  status=0x0003,    refclock_status="UTC DISPLAY; TIME CODE; PPS; POSITION; (LEAP INDICATION;    PPS SIGNAL; POSITION)",    refclock_format="Meinberg GPS Extended",    refclock_states="*NOMINAL: 21:21:36 (99.99%); FAULT: 00:00:03 (0.00%);    running time: 21:21:39",    refclock_id="GPS", refclock_iomode="normal",    refclock_driver_version="refclock_parse.c,v 4.77 2006/08/05 07:44:49    kardel RELEASE_20060805_A",    meinberg_gps_status="[0x0000] &lt;OK&gt;",    gps_utc_correction="current correction 14 sec, last correction    on c7619a00.00000000  Sun, Jan  1 2006  0:00:00.000",    gps_message="/PFU3SOP-4WG14EPU0V1KA",    meinberg_antenna_status="RECONNECTED on 2006-07-18 08:13:20.0000000 (+0000)    UTC CORR, LOCAL TIME, reconnect clockoffset +0.0000000 s,    disconnect time 0000-00-00 00:00:00.0000000 (+0000) ",    gps_tot_51="week 1400 + 3 days + 42300.0000000 sec",    gps_tot_63="week 1400 + 3 days + 42294.0000000 sec",    gps_t0a="week 1400 + 5 days + 71808.0000000 sec",    gps_cfg[1]="[0x9] BLOCK II", gps_health[1]="[0x0] OK;SIGNAL OK",    gps_cfg[2]="[0x0] BLOCK I", gps_health[2]="[0x3f] PARITY;MULTIPLE ERRS",    gps_cfg[3]="[0x9] BLOCK II", gps_health[3]="[0x0] OK;SIGNAL OK",    gps_cfg[4]="[0x9] BLOCK II", gps_health[6]="[0x0] OK;SIGNAL OK",    gps_cfg[5]="[0x9] BLOCK II"  		</pre>
    <h4>Fudge Factors</h4>
    <dl>
      <dt>time1 <em>time</em> </dt>
      <dd>Specifies the time offset calibration factor, in seconds and fraction. The default value depends on the clock type. </dd>
      <dt>time2 <em>time</em> </dt>
      <dd> If flag1 is 0, time2 specifies the offset of the PPS signal from the actual time (PPS fine tuning). </dd>
      <dd> If flag1 is 1, time2 specifies the number of seconds a receiver with a  premium local oscillator can be trusted after losing synchronisation. </dd>
      <dt>stratum <em>stratum</em> </dt>
      <dd>The stratum for this reference clock. </dd>
      <dt>refid <em>refid</em> </dt>
      <dd>The refid for this reference clock. </dd>
    </dl>
    <dl>
      <dt>flag1 { 0 | 1 } </dt>
      <dd>If 0, the fudge factor time2 refers to the PPS offset. </dd>
      <dd>If 1, time2 refers to the TRUST TIME. </dd>
      <dt>flag2 { 0 | 1 } </dt>
      <dd>If flag2 is 1, sample PPS on CLEAR instead of on ASSERT. </dd>
      <dt>flag3 { 0 | 1 } </dt>
      <dd>If flag3 is 1, link kernel PPS tracking to this refclock instance. </dd>
      <dt>flag4 { 0 | 1 } </dt>
      <dd>Delete next leap second instead of adding it. (You'll need to wait a bit for that to happen 8-) </dd>
    </dl>
    Note about auxiliary Sun STREAMS modules (SunOS and Solaris):<br>
    <dl>
      <dt>The  timecode of these receivers can be sampled via a STREAMS module in the  kernel. (The STREAMS module has been designed for use with Sun systems  under SunOS 4.1.x or Solaris 2.3 - 2.8. It can be linked directly into  the kernel or loaded via the loadable driver mechanism.) This STREAMS  module can be adapted to convert different time code formats. Nowadays  the PPSAPI mechanism is usually used. </dt>
    </dl>
    <h4>Making your own PARSE clocks</h4>
    <p>The parse  clock mechanism deviates from the way other NTP reference clocks work.  For a short description of how to build parse reference clocks, see <a href="../parsenew.html">making PARSE clocks</a>.</p>
    <p>Additional Information</p>
    <p><a href="../refclock.html">Reference Clock Drivers</a></p>
    <hr>
    <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
  </body>
</html>
